デザインチームでスクラムをやろうと思った話
こんにちは。CX事業本部でデザインチームのマネージャーをしている小峰です。2023年2月に入社して約半月ほどが経過し、情報収集を進めていったところでチームとしてスクラムをやってみてはどうかと思い至り、その経緯について書いてみます。
背景
デザイナーがアジャイルプロセスの中でどうコミットしていくか、といった悩みや試行錯誤の発露をウェブで検索してみると見て取れます。
社内で何人かと1on1やミーティングを通して、我々も同様にスクラムのプロセスにデザイン作業が上手く組み込めないという悩みを持っている方々がいることを知りました。さらに話を聞いていくと、どうやらアジャイルの考え方やスクラムといった開発手法に対する基本的な理解や慣れを得ないまま開発プロセスに入ってしまっている状況も多少あるようです。CX事業本部では多彩なお客様とプロジェクトを推進していることもあり、杓子定規的な解決は望めません。アジャイルでよく言われる「銀の弾丸がない」ということと同義で、多様な環境への最適化が必要です。
そこでまずはミニマムでプレーンなスクラムをデザインチームでやってみてはどうか、と思い至りました。
見込む効果
ベースとなる部分の理解が深まることによる各プロジェクトでのデザイン活動の最適化が期待できます。
これを書いている時点での最新のスクラムガイド（2020年11月版）にも記載されいてる通り、スクラムはソフトウェア開発に限った開発手法ではありません。ということは各プロジェクトのプロダクト開発、ソフトウェア開発がゴールでなくても問題ないわけです。
我々のデザインチームは各案件のデザイン業務はもちろんのこと、各種イベントにおけるクリエティブ制作、ロゴデザインなど多岐にわたる業務を担当しています。ひとつのプロダクトに絞ったスクラムを構築することはできませんから、すべてのデザインチームの成果物をプロダクトとみなし、その業務円滑化、品質向上をプロダクトゴールとみなせるのではないかと現時点では考えています。
この活動を通して、アジャイルの考え方、スクラムのやり方の理解が今まで以上に深まり、特にデザイナー視点での各プロジェクトの開発プロセスの改善を推し進めることに繋がるはずです。
いきなりスクラムはやらない
とはいえ急にスタートしても戸惑いが多いことが予想されます。各プロジェクトのアジャイル度合いもそれぞれですし、一口にスクラムといっても実際の開発プロセスは千差万別です。
というわけで、ちょうど自分が入ったばかりということもあり「ドラッカー風エクササイズ」から着手することにしました。有名なのでご存知の方も多いかと思いますがアジャイルサムライの著者であるるJonathan Rasmusson氏が紹介しているチームビルディングの手法です。私は書籍チームジャーニーで知りました。
基本的に4つの質問にチームメンバーが答えて共有する、というものですがその質問は結構ハードというか深いというか、なかなか大変です（笑）
- 自分は何が得意か？
- どうやって貢献するか？
- 大切に思う価値は何か？
- 周囲のメンバーが自分に対してどんな期待を抱いていると思うか？
詳しく解説や紹介しているウェブサイトが沢山ありますので、興味がある方は「ドラッカー風エクササイズ」で検索していただけると良いかと思います。
新しいメンバーが入ったタイミングというのはチームメンバーが自分たちを見つめ直す良いチャンスなので、やってみることにしました。
早速「ドラッカー風エクササイズ」をやってみた
というわけでやってみましたドラッカー風エクササイズ。これをファシリテートしたのはだいぶ久しぶりでしたが、皆さん楽しみながら参加いただけたようです。私が入社する前からチームメンバーだった皆さんですが、改めてお互いのことを知り、かつ、自分のことも見つめ直すことができた時間となりました。
この対話を通して「お互いを知ること」「感触を得ること」が大事であり、何かを決めて行動していくことは次のステップです。
こういった取り組みはチームが何かを決めて行動することを滑らかにするための潤滑油となるようなものだと、自分は考えています。1度やって終わりではなく、不定期に行うと忘れていたことを思い出したり、勘違いしていたりすることを発見でき、軌道修正もできるのでオススメです。
また、「チーム」と「グループ」の違いをお伝えしました。これは書籍「チームジャーニー」からの引用です。
自分たちがどんな状態なのか、まずはこの「チーム」と「グループ」の違いから差分を取ってみるのが手を付けやすいのでよく参照しています。
スクラム導入までのステップ案
そういう考え方の元、今後の流れを書いてみました。
- 皆さんがお互いに価値観や将来像を知る
- より良いチームとなるためのファーストステップとする
- アジャイルとスクラムの違いを改めて知る
- 原理原則・マインドセットと開発手法であることを知る
- 銀の弾丸ではないことを知る
- スクラムのプロセスについてきちんと理解する
- スクラムガイドを改めて読み、解釈し、理解する
- インセプションデッキを作る
- 私たちはなぜここにいて、何のために、何を目指すのかを自分たちで決める
- 従来のプロセスの「むきなおり」を行う
- いわゆるUnlearn。再構成して新しいチャレンジをやりやすくする
- 各プロジェクトとは分離したチームのPBL（プロダクトバックログ）を作る
- どんな優先度で、何をやっていて、どのくらいの負荷がかかっていて、今後何をすべきなのか、チームの状況を可視化すると共にチームの目指すべき方向性を実現するためのタスクを決める
- スプリントイベントを設計する
- デイリースクラム、プランニング、レビュー、ふりかえりを組み立てる
- やってみる
- 守破離の「守」からはじめる
この後はやってみた結果から次に何をすべきかを考えていくことになります。「デザイン思考」を学んだり「デザインスプリント」や「LeanUX」を取り込んでいくことになるかもしれません。が、それもやってみた結果次第です。
最後に
この取り組みは始まったばかりです。スクラムは大雑把に言ってしまえば反復的な改善のプロセスですので、続けていくことでどんどん良くなっていくはずです。
またいずれ、経過や活動の中から得られた気づきであったりについて書きたいなと思います。
